原帖 ｜ Jack ｜ 2025-11-05 20:59 ｜ 👍2 ｜ 阅读约1
面试官问：RT-Thread 这些开源框架本来就把底层做得挺好了，为什么我们还要花精力再去做一套架构分层？
答：
我不反对直接用 RT-Thread 的生态，事实上我们也用了它的很多能力。但我在项目里做分层不是为了‘重复造轮子’，而是为了解决我们业务里长期会反复遇到的可维护性和可移植性问题。
具体讲三点、和一个落地案例：
（RTOS 基础概念可先过一遍 结合了我们学员面试，总结了RTOS面试时常见问题：，再回头看分层的必要性。）
1.消除厂商/OS 绑定，降低切换成本
我们把 OS 能力（线程/同步/时间基准）抽成 OSAL，把外设能力抽到 Handler/Driver 两层——Handler 只面向业务接口、Driver 只面向寄存器和 HAL。这样后面从 FreeRTOS 切到 RT-Thread，或者从 STM32F4 切到 H7/GD32/NRF，只需要换 Adapter，不动上层逻辑。
案例：AHT21/DHT11 同类温湿度传感器的运行时挂载。产线临时替换器件时，不改 APP、不重新编译，通过标志位选择驱动，半小时就能把线拉起来；这在纯粹依赖某个 BSP 写法时往往要重编。
2.把‘编译期耦合’改成‘运行时链接’
很多项目初期图快，直接在编译期把外设依赖写死，后期一旦要并行上新器件或做 A/B 方案评估，改动面很大。我们用“注册器 + 适配器 + 工厂”组合，把 SPI/I²C/UART 这些底层通道通过依赖注入喂到 Handler。
案例：W25Q 系列从 Q64 换到 Q128，SPI/QSPI 两种实现都能通过 Adapter 插进去，不动上层 FlashMgr。上线周期至少能省一周调试量。
3.为低功耗、OTA、可观测性预留统一的‘系统位面’
RT-Thread 把内核做好没问题，但低功耗策略、Boot/OTA 回滚、日志/自检这些是强业务相关的“系统约束”。
我们把它们固定在中间件层面做统一约定：
Idle/Tickless/STOP 的决策在 PowerMgr 线程，不让业务线程各自为政；
Boot/AES/CRC/回滚策略对 APP/驱动透明；
日志/看门狗/错误线程三件套，保证现场可回溯。
结果：同样场景下，平均功耗从 ~6.2 mA 降到 ~5 mA；OTA 故障回滚把“变砖率”从偶发现象→0（最近两个小批次）。
总结：我们不是和 RT-Thread 竞赛，而是用分层把“平台独立 + 业务稳定 + 可运维”这三件事钉住。这样后面无论换 OS、换芯片、扩品类，团队都能“快而稳”。
相关笔记